From time to time our customers report memory leaks in their applications which use SciChart. Sometimes memory leaks are caused by customer code, and sometimes by SciChart code.

Usually memory leaks caused by SciChart are resolved within a few days and a fix is pushed to our Nightly Build feed, as we consider these to be high priority issues.

In this article we are going to talk about the approach we take to diagnosing memory leaks and what we will need from you to solve these kinds of issues quickly.

Freeing Memory Held by SciChart

SciChart is designed to automatically manage and dispose of unmanaged resources when a SciChartSurface or SciChart3DSurface goes out of scope (i.e., when no references to it remain). In most cases, you do not need to take any special action to free memory — .NET's garbage collector (GC) will handle it.

DataSeries Memory Handling

One of the largest memory consumers in SciChart are the DataSeries, which hold the actual X and Y data. When they go out of scope, the memory they occupy is typically reclaimed by the garbage collector shortly after.

However, if you need to release memory explicitly (e.g., during long-running sessions or when switching datasets), you can call the Clear() method on your DataSeries:

dataSeries.Clear(releaseMemory: true);

Passing “true” ensures internal caches are also cleared and the memory is released immediately.

Manual Disposal of SciChartSurface

While most memory management is automatic, it's important to note that the .NET garbage collector does not guarantee timely or reliable cleanup of unmanaged resources. This can lead to memory leaks, particularly under high memory pressure.

To handle this, both SciChartSurface and SciChart3DSurface implement the Dispose and Finalizer patterns. If you’re experiencing high memory usage or want to explicitly release resources, you should manually call Dispose() to ensure immediate release of native memory:

sciChartSurface.Dispose();
// or
sciChart3DSurface.Dispose();

Checklist: When You discover a memory leak

If you think memory is leaking in your application, take a moment to run through this checklist before contacting support.

1. Is memory actually leaking? Or is it just rising?
2. What is causing the memory leak? Do some memory profiling (using SciTech Memory Profiler, or dotMemory or ANTS Profiler)
3. Isolate code which causes the leak.
4. Send this code to us (include profiling results if you have them)

Step 1: Is Memory Leaking?

When discovering memory is rising in your applcation, do some quick work to see if memory is leaking or if it is just rising.

For example, if you are appending lots of points to the chart you can expect the memory to rise. You can also expect that memory to be reclaimed when the SciChartSurface / DataSeries holding the data is no longer referencing by anything in your application.

You can check for a memory leak by doing a repeated operation again and again and seeing if the memory continues to rise, or is reclaimed.

You can force a Garbage Collection operation by using this code: How to force a Garbage Collection.

// Use this to test if the memory is leaking after you null
// all references to a SciChartSurface
GC.Collect();
GC.WaitForPendingFinalizers();

Step 2: What is causing the memory leak?

If you are now certain that memory is leaking, the next step is to determine what is causing the memory leak. To do this, you can use a memory profiler. Memory profilers include:

• SciTech Memory Profiler - bonus points, they are also a SciChart customer!
• JetBrains dotMemory 
• ANTS Profiler

In this video at 1m44s we show how to use a memory profiler to identify the shortest path to GC Roots (what is holding the memory) by getting a snapshot in dotTrace and exploring the shortest path to GC Roots to identify what is holding on to the memory.

This can reveal something interesting about your application. Maybe it is something in your code which is holding on to the memory? Maybe it is something in ours.

Typical memory leak culprits include:

• Static Dictionaries, Lists or Variables that are used and never cleared.
• Event handler subscriptions which are never unsubscribed.
• Deadlocked threads or blocked finalisers.
• Bugs in the .NET Framework or WPF (yes they do happen)

Step 3: Isolate code which causes the leak

Say you have performed the steps above and you're pretty sure that there is a memory leak when SciChart is used in a particular way. Now, isolate the code which causes the leak and send it to us.

Even if you are not a supported customer we will endevour to look into memory leaks as a matter of urgency. Hopefully, we can provide a fix quickly and get you back to work as soon as possible!